home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940306.txt < prev    next >
Internet Message Format  |  1994-11-13  |  21KB

  1. Date: Wed, 14 Sep 94 04:30:25 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #306
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Wed, 14 Sep 94       Volume 94 : Issue  306
  11.  
  12. Today's Topics:
  13.            [Q] packet TV; broadband IP coder to TV signal? 
  14.                         DX Cluster on Internet
  15.                          HDLC protocol chips
  16.                           JNOS 1.10f lockups
  17.                           mocom 35 on packet
  18.                  Using internet for DX spots (4 msgs)
  19.                        VHF packet "talk" range
  20.                           WNOS memory leak?
  21.  
  22. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  23. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  24. Problems you can't solve otherwise to brian@ucsd.edu.
  25.  
  26. Archives of past issues of the Ham-Digital Digest are available 
  27. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  28.  
  29. We trust that readers are intelligent enough to realize that all text
  30. herein consists of personal comments and does not represent the official
  31. policies or positions of any party.  Your mileage may vary.  So there.
  32. ----------------------------------------------------------------------
  33.  
  34. Date: Sat, 10 Sep 1994 17:29:00 GMT
  35. From: agate!howland.reston.ans.net!EU.net!sun4nl!knowar!NewsWatcher!user@ames.arpa
  36. Subject: [Q] packet TV; broadband IP coder to TV signal? 
  37. To: ham-digital@ucsd.edu
  38.  
  39. Have there been any experiments;
  40.  
  41. It resembles VCR backup for digital data.
  42.  
  43. A minimal packet would be a bitstream encoded into a regular TV signal
  44. frame with sync, error correction, address etc. . Maybe some teletekst(see
  45. note) technology could be used for this not only for the top video lines
  46. but for the whole "picture" frame / packet.
  47.  
  48. NOTE: Teletekst is a system wich uses the top video lines (invisible) to
  49. broadcast digital data to all tv sets continuously; the user selects from
  50. the carrousel pages to read.
  51.  
  52. PE1BFE
  53.  
  54. ------------------------------
  55.  
  56. Date: 13 Sep 94 21:39:53 GMT
  57. From: news-mail-gateway@ucsd.edu
  58. Subject: DX Cluster on Internet
  59. To: ham-digital@ucsd.edu
  60.  
  61. Well Im not infavour of this..
  62. what ever happend to CQ CQ CQ and tuning about ??
  63. Now with Internet connect and DX Clusters You can simply
  64. go to a DX spot connect on the Internet join the DX cluster
  65. Announce to All Im on 14.045 or 28.675 what ever
  66. And setup the skeds.
  67. What a Cheet Hi Hi..
  68. Ill try it next time im on St.Kilda VR18g and Op on 144 or 432Mhz.
  69. Barry GM8SAU/DC0HK..
  70.  
  71. ------------------------------
  72.  
  73. Date: Sat, 10 Sep 1994 17:41:20 GMT
  74. From: agate!spool.mu.edu!news.clark.edu!netnews.nwnet.net!chena.alaska.edu!raven.alaska.edu!ftpam.uafsoe.alaska.edu!ftpam@ames.arpa
  75. Subject: HDLC protocol chips
  76. To: ham-digital@ucsd.edu
  77.  
  78. In article <34mb4g$7n9@news.u.washington.edu> kenth@u.washington.edu (Kent Hill) writes:
  79. >Path: raven.alaska.edu!chena.alaska.edu!netnews.nwnet.net!news.u.washington.edu!kenth
  80. >From: kenth@u.washington.edu (Kent Hill)
  81. >Newsgroups: rec.radio.amateur.digital.misc
  82. >Subject: HDLC protocol chips
  83. >Date: 8 Sep 1994 06:31:44 GMT
  84. >Organization: University of Washington, Seattle
  85. >Lines: 19
  86. >Sender: kenth@u.washinton.edu
  87. >Message-ID: <34mb4g$7n9@news.u.washington.edu>
  88. >NNTP-Posting-Host: carson.u.washington.edu
  89.  
  90.  
  91. >I've been working on a homebrew tnc design for a while to convert an old 8-bit
  92. >atari to a tnc.  I had designed the system around using a Western Digital 1933
  93. >HDLC chip, but when I went to buy one about a year ago, WD told me they don't
  94. >make it any more.  Soo.. after looking around I thought Zilogs Z8530 (as used
  95. >in other TNCs) should work, but when I tried to call them to get the technical
  96. >specs the numbers I found for them didn't work (ok i got them out of 1983 
  97. >book).  The Motorola 6854 doesn't have an internal PLL clocking mode.  Does 
  98. >any one know where I can either
  99.  
  100. >1. Get a wd1933 with specs
  101. >        or
  102. >2. Get a hold of Zilog
  103. >        or
  104. >3. Another chip that might work?
  105.  
  106. >Thanks for the help
  107.  
  108. >kenth@u.washinton.edu
  109.  
  110. Advanced Micro Devices also manufactures the Z8530 as the Am85C30.  Call 
  111. 1-800-222-9323 and ask for the Am85C30 Data Sheet and the Am8530H/Am85C30 
  112. Technical Manual.  The AMD CMOS part has some enhancements useful for high 
  113. speed HDLC operation.
  114.  
  115. Intel also manufactures the Z8530 as the 82530.  You can call them at 
  116. 1-800-628-8686 and ask for their data sheet, but I found the information from 
  117. AMD more useful.
  118.  
  119. I obtained 8530 literature from both AMD and Intel just a couple of weeks 
  120. ago, so both of the 800 numbers should still be good.  Most hobbyist component 
  121. vendors sell Z8530 or Z85C30's.  Newark Electronics catalogs the AMD CMOS part.
  122.  
  123. Another device you might investigate is the 82520/82525/82526 series from 
  124. Siemens.  (AMD used to make these, too, but I don't know if they still do.)  
  125. These have selectable bus structures that match either Intel 8080 or Motorola 
  126. 6800 bus arrangements.  The latter would probably match the 6502 in your Atari 
  127. better.
  128.  
  129. A third possibility is to throw away the Atari :-) and use one of the new 
  130. microcontrollers with integrated HDLC.  Intel sells the 80C152 and Zilog has 
  131. a device (whose part number escapes me at the moment) that includes Z80, glue, 
  132. clock generator, and half a Z8530.  National Semiconductor catalogs a COP1600 
  133. variant with integrated HDLC, but if I remember right it doesn't have the DPLL 
  134. for clock recovery.
  135.  
  136. ------------------------------
  137.  
  138. Date: 12 Sep 1994 19:27:57 -0500
  139. From: ihnp4.ucsd.edu!newshub.nosc.mil!crash!news.sprintlink.net!bga.com!bga.com!nobody@network.ucsd.edu
  140. Subject: JNOS 1.10f lockups
  141. To: ham-digital@ucsd.edu
  142.  
  143. In article <5K8QuT+.kb0kqa@delphi.com>, Matt Werner  <kb0kqa@delphi.com> wrote:
  144. >I've tried turning the watchdog timer on, especially because the system is
  145. >a remote system, but it's been down for two days now, and the watchdog timer
  146. >is 300 seconds!  
  147.  
  148. The watchdog timer works by detecting that the timer process is blocked 
  149. when the hardware timer interrupt ticks.  If timer interrupts are blocked
  150. (usually because all interrupts are off), then the watchdog code doesn't
  151. run.   
  152.  
  153. >                 Any other suggestions on how I can keep it online without
  154. >putting it on a timer to reset the computer every day?  It seems like it will
  155. >run for a few days before it locks, and it usually locks up with plenty of
  156. >memory (50k or so, but DOS is loaded low).  Would it help to load DOS high,
  157. >or wouldn't it really matter in this case?  Any suggestions?
  158.  
  159. If you load dos high then you will get some extra memory.  What is going
  160. on when it locks up?  Does your caps lock key work?  Can you type more
  161. than 16 charactesrs without getting beeps?  Can you use the 3 finger
  162. salute or do you have to press the hardware reset button?
  163.  
  164. One thing you can try is reducing features.  Compile out code you don't
  165. need, don't start more sessions at the same time than you need, keep
  166. an eye on sockets where the other end died, etc.  Consider doing a
  167. software exit/restart or reboot every x hours as a preventitive measure.
  168.  
  169. Another choice that is equally drastic software wise but is easer
  170. on the hardware would be to put a connection that activates the
  171. reset line.  You could even hook it up to do it remotely (on 440
  172. or above) instead of on a timer.  Or make a hardware watchdog that
  173. activates the reset if you don't write to it within say 5 minutes
  174. and add that to the timer loop.
  175.  
  176. milton
  177. --
  178. Milton Miller  KB5TKF  miltonm@bga.com 
  179.  
  180. ------------------------------
  181.  
  182. Date: 9 Sep 94 22:01:00 GMT
  183. From: elroy.jpl.nasa.gov!swrinde!gatech!wa4mei!totrbbs!steve.diggs@ames.arpa
  184. Subject: mocom 35 on packet
  185. To: ham-digital@ucsd.edu
  186.  
  187. -> Newsgroups: rec.radio.amateur.digital.misc
  188. -> Subject: mocom 35 on packet
  189. -> From: dave.baumwald@woodybbs.com (Dave Baumwald)
  190. -> Message-ID: <93.2333.7582.0NFB30E6@woodybbs.com>
  191. -> Date: Thu,  8 Sep 94 05:45:00 -0500
  192. ->
  193. -> Has anyone ever used a Motorola Mocom 35 on packet? If so have you
  194. -> had any problems? Thanks for any advice!
  195.  
  196. We use a Mocom 35 as our main 1200 baud digi here in Atlanta, W4Q0-1. It
  197. is an excellent performer.
  198.  
  199. Regards,
  200. Steve Diggs
  201. President, East Atlanta LAN
  202.  
  203. ----
  204. Top Of The Rock BBS - Lilburn, GA         SYSOP: Steve Diggs
  205. UUCP: totrbbs.atl.ga.us               Snailmail: 4181 Wash Lee Ct.
  206. Phone: +1 404 921 8687                           Lilburn, GA 30247-7407
  207.  
  208. ------------------------------
  209.  
  210. Date: Sun, 11 Sep 94 21:14:37 MST
  211. From: ihnp4.ucsd.edu!newshub.nosc.mil!crash!news.sprintlink.net!primenet!stat!david@network.ucsd.edu
  212. Subject: Using internet for DX spots
  213. To: ham-digital@ucsd.edu
  214.  
  215. rapp@lmr.mv.com (Larry Rappaport) writes:
  216.  
  217. > david@stat.com (David Dodell) writes:
  218. > > rapp@lmr.mv.com (Larry Rappaport) writes:
  219. > > 
  220. > > > Internet which aren't all that common. Another way might be via IRC (Inte
  221. > > > Relay Chat) which allow users to connect to an IRC server when interested
  222. > > > and look for a channel called DX or some such. Using IRC would mean that
  223. > > > anyone with a cheap interactive account could use it, it could be used bo
  224. > > 
  225. > > I think this is an excellent idea ... this would allow something to be
  226. > > immediately in operation with a resource that already exists
  227. > > 
  228. > > david wb7tpy
  229. > Well, actually, on further thought, it isn't so excellent. :) How do you keep
  230. > non-hams out of it? Anybody checking in and posting will end up making a
  231. > transmission, which I don't think is legal.  :(
  232.  
  233. I think the suggestion was to use IRC as a DX spot on it's own, not to
  234. gate it to the radio.  Nothing illegal about that.
  235.  
  236. ---
  237. Editor, HICNet Medical Newsletter
  238. Internet: david@stat.com                 FAX: +1 (602) 451-1165
  239. Bitnet  : ATW1H@ASUACAD
  240.  
  241. ------------------------------
  242.  
  243. Date: Sat, 10 Sep 1994 11:17:00 PST
  244. From: ihnp4.ucsd.edu!sdd.hp.com!swrinde!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!mala.bc.ca!news.island.net!ham!emd@network.ucsd.edu
  245. Subject: Using internet for DX spots
  246. To: ham-digital@ucsd.edu
  247.  
  248. david@stat.com (David Dodell) writes:
  249.  
  250. >rapp@lmr.mv.com (Larry Rappaport) writes:
  251. >
  252. >> Internet which aren't all that common. Another way might be via IRC (Internet
  253. >> Relay Chat) which allow users to connect to an IRC server when interested,
  254. >> and look for a channel called DX or some such. Using IRC would mean that
  255. >> anyone with a cheap interactive account could use it, it could be used both
  256. >
  257. >I think this is an excellent idea ... this would allow something to be
  258. >immediately in operation with a resource that already exists
  259. >
  260.  
  261. What's even more astounding is that packet hasn't taken advantage of the 
  262. many inexpensive or free DOS based uucp news and mail forwarding systems 
  263. to allow for, for example, newsgroups instead of having every subject in 
  264. one main group. Waffle, for example, ought to work very well over Packet, 
  265. and runs on any DOS machine, even XT's.
  266.  
  267. --
  268. emd@ham.island.net (Robert Smits, VE7EMD Ladysmith BC)
  269.  
  270.    " I admire Ted Kennedy. How many 59-year-olds do you know who 
  271.      still go to Florida for spring break?" - Pat Buchanan
  272.  
  273. ------------------------------
  274.  
  275. Date: Sat, 10 Sep 1994 12:16:30 GMT
  276. From: mvb.saic.com!unogate!news.service.uci.edu!usc!howland.reston.ans.net!swiss.ans.net!solaris.cc.vt.edu!news.duke.edu!concert!hearst.acc.Virginia.EDU!murdoch!brain.neuro.@@ihnp4.ucsd.edu
  277. Subject: Using internet for DX spots
  278. To: ham-digital@ucsd.edu
  279.  
  280. In article <Cvv7K2.LD7@cscsun.rmc.edu>,
  281. David Tiller <dtiller@cscsun.rmc.edu> wrote:
  282. >Has anyone given any thought to using the internet to transport DX cluster
  283. >spots?  I was listening to my local node last night, and it seemed to me
  284. >that that sort of information would lend itself to long haul tunnelling
  285. >through the internet.  It would also be neat to have a server available
  286. >online to see DX during the day...:-)  I was thinking maybe a slick X
  287. >interface, or a WWW page with a map and all.... What do you think?  Would
  288. >it be worth writing some code and sticking a TNC in the air?  To start with
  289. >we could just have one large collection of "listens" without retransmitting
  290. >spots.  That could be added later.  Naturally you could choose which regions
  291. >and servers you'd want to accept..Here in Va I don't care about MooseJaw's
  292. >DX!!!
  293.  
  294. I too would love to have the capability to get spots on Internet.  I have
  295. lousy access to PacketCluster anyway but great access to Inet.  I'm surprised
  296. it hasn't been done yet. Problem is getting the code writted and into the
  297. field and then what's the incentive for people to post spots?
  298.  
  299. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
  300.   Ned Hamilton    AB6FI            NTC       Department of Neurosurgery
  301.   nedh@virginia.edu                          University of Virginia
  302. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
  303.  
  304. ------------------------------
  305.  
  306. Date: 11 Sep 1994 03:50:22 GMT
  307. From: ihnp4.ucsd.edu!news.cerf.net!nntp-server.caltech.edu!netline-fddi.jpl.nasa.gov!elroy.jpl.nasa.gov!swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org!k9cw@network.ucsd.edu
  308. Subject: Using internet for DX spots
  309. To: ham-digital@ucsd.edu
  310.  
  311. In a previous article, esh6n@brain.neuro.virginia.edu (Ned Hamilton) says:
  312. >
  313. >                     Problem is getting the code writted and into the
  314. >field and then what's the incentive for people to post spots?
  315. >
  316. I think your last point is the most important issue.  How many of us have a 
  317. full time link to internet while sitting in front of our radios?  Without 
  318. people sitting next to radios, who is going to generate these DX spots?
  319. And if you are at work or the university lab, are you in any position to do
  320. something about a new country that is spotted someplace else in the country?
  321. If you are at work, what DX spots can you contribute?  PacketCluster only
  322. works when we have people tuning the bands and sending DX spots. 
  323.  
  324. Using internet to link remote cluster nodes makes sense to me if there is 
  325. no direct radio path.  Sending those spots to users dialed in to internet
  326. does not. 
  327.  
  328. 73, Drew
  329. -- 
  330. *-----------------------------*-------------------------------------*
  331. |    Andrew B. White  K9CW    |    internet: k9cw@prairienet.org    |
  332. |    ABW Associates, Ltd.     |   phone/fax: 217-643-7327           |
  333. *-----------------------------*-------------------------------------*
  334.  
  335. ------------------------------
  336.  
  337. Date: 12 Sep 94 16:03:47 -0700
  338. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!news.cs.utah.edu!cs.utexas.edu!swrinde!sgiblab!uhog.mit.edu!news.mtholyoke.edu!news.byu.edu!yvax.byu.edu!barrusc@network.ucsd.edu
  339. Subject: VHF packet "talk" range
  340. To: ham-digital@ucsd.edu
  341.  
  342.     Can anyone tell me if it is possible to "talk" via packet VHF over long
  343. distances by linking digipeaters?  What is the longest distance?  
  344.  
  345.     I am looking to getting into packet and was just curious.  73's
  346.  
  347. Craig
  348.  
  349. ------------------------------
  350.  
  351. Date: 13 Sep 94 03:40:01 GMT
  352. From: gonix!russell@uunet.uu.net
  353. Subject: WNOS memory leak?
  354. To: ham-digital@ucsd.edu
  355.  
  356.     I'm running WNOS (Title line WNOS.4A9.DB3FL) on my packet machine, and
  357. I love it, but it seems that the memory just continually goes down when I
  358. leave the machine on for any length of time.  I've tried shutting the
  359. trace off, set the ax heard list to the last 25 only, etc etc, but still
  360. it just goes down.
  361.  
  362.     Is there a memory leak somewhere, or is the system just letting things
  363. go until it gets low enough, at which point it will garbage-collect and
  364. free things up?  I haven't left it on and watched it to see.  I'd like to
  365. set up a remote routing system, but not if it's going to reboot quite
  366. often due to memory problems.
  367.  
  368.                 Tim, russell@gonix.com
  369.                 n0zhy@wd0har.#ene.ne.usa.noam
  370.  
  371. ------------------------------
  372.  
  373. Date: 10 Sep 1994 23:30:10 GMT
  374. From: agate!spool.mu.edu!news.clark.edu!netnews.nwnet.net!news.u.washington.edu!kenth@ames.arpa
  375. To: ham-digital@ucsd.edu
  376.  
  377. References <34mb4g$7n9@news.u.washington.edu>, <D>, <ftpam.46.003001AE@aurora.alaska.edu>ws
  378. Subject : Re: HDLC protocol chips
  379.  
  380. thanks for all your responses.  I've been able to find the stuff I need
  381.  
  382. kenth@u.washington.edu
  383.  
  384. ------------------------------
  385.  
  386. Date: 12 Sep 1994 20:55:06 GMT
  387. From: sunic!isgate!news.rhi.hi.is!ddietz@uunet.uu.net
  388. To: ham-digital@ucsd.edu
  389.  
  390. References <RSNYDER.94Sep9154242@boot108a.astro.ge.com>, <34st8u$qgk@tequesta.gate.net>, <rsnyder-1009941711490001@wintermute.motown.ge.com>
  391. Subject : Re: KPC-9612/Starting out
  392.  
  393. In <rsnyder-1009941711490001@wintermute.motown.ge.com> rsnyder@astro.ge.com (Bob Snyder) writes:
  394.  
  395. >In article <34st8u$qgk@tequesta.gate.net>, anto@gate.net (Nigel Kirlew) wrote:
  396.  
  397. >> The KPC-9612 would be my choice if I were buying today. The ability to
  398. >> operate 1200 and 9600 baud simultaneously is a big plus. May not be
  399. >> important to you, but it's really like having two independent modems in one 
  400. >> box.
  401.  
  402. >It might be important to me....  I don't know yet. :-)  I would probably
  403. >tend to want 9600, if it's in much use.  But if it's not much use to me,
  404. >and isn't likely to be such in the near future, would I be better off
  405. >getting a 1200 baud TNC now, and wait and get something like advanced
  406. >units later....
  407.  
  408. If you can afford the cost of the KPC-9612 now, then buy it now, or you'll
  409. regret it later.  The point here is that it does have both 1200 and 9600
  410. baud capability, and they can run simultaneously.  This means that you
  411. could get started now, using only the 1200 baud port, and easily move up
  412. to 9600 baud with another rig later on.
  413.  
  414. >> For 9600 baud, they all require precise deviation adjustment. You're
  415. >> also not likely to run 9600 baud with your HT (not a trivial mod). I see
  416. >> another radio in your future :-)
  417.  
  418. >Oh, goody.  What budget? :-)  What should I be looking for in a new rig? 
  419. >I know newer rigs can switch faster, which is a major plus, but what about
  420. >the "packet ready" radios?  Are those worth the money?  What is it?
  421.  
  422. >Can you attach the KPC-9612 to a HT and run it at 1200 anyway?  I have
  423. >visions of plugging a 9-volt into the TNC, and taking my HT and Newton out
  424. >and run packet away from the apartment. :-)
  425.  
  426. This is exactly what the KPC-9612 and older KPC-3 are really good for. 
  427. Running low power, in the field, on batteries only.
  428.  
  429. >Also, can the KPC-9612 do HF packet?
  430.  
  431. A resounding NO, comes to mind here.  This is only good for vhf and above
  432. due to the modulating frequency shift size.  It results in too large a
  433. bandwidth for use on hf bands...
  434.  
  435. >Bob N2KGO
  436. >-- 
  437. >Bob Snyder
  438. >rsnyder@astro.ge.com
  439.  
  440.  
  441. Hope this helps.
  442.  
  443. 73 de Don, n3kfh /tf8
  444. n3kfh@centrum.is
  445.  
  446. ------------------------------
  447.  
  448. Date: Sat, 10 Sep 1994 17:11:49 -0400
  449. From: netnews.upenn.edu!news.drexel.edu!news.ge.com!wintermute.motown.ge.com!user@RUTGERS.EDU
  450. To: ham-digital@ucsd.edu
  451.  
  452. References <1994Sep9.075319.26698@cc.usu.edu>, <RSNYDER.94Sep9154242@boot108a.astro.ge.com>, <34st8u$qgk@tequesta.gate.net>edu
  453. Subject : Re: KPC-9612/Starting out
  454.  
  455. In article <34st8u$qgk@tequesta.gate.net>, anto@gate.net (Nigel Kirlew) wrote:
  456.  
  457. > The KPC-9612 would be my choice if I were buying today. The ability to
  458. > operate 1200 and 9600 baud simultaneously is a big plus. May not be
  459. > important to you, but it's really like having two independent modems in one 
  460. > box.
  461.  
  462. It might be important to me....  I don't know yet. :-)  I would probably
  463. tend to want 9600, if it's in much use.  But if it's not much use to me,
  464. and isn't likely to be such in the near future, would I be better off
  465. getting a 1200 baud TNC now, and wait and get something like advanced
  466. units later....
  467.  
  468. > For 9600 baud, they all require precise deviation adjustment. You're
  469. > also not likely to run 9600 baud with your HT (not a trivial mod). I see
  470. > another radio in your future :-)
  471.  
  472. Oh, goody.  What budget? :-)  What should I be looking for in a new rig? 
  473. I know newer rigs can switch faster, which is a major plus, but what about
  474. the "packet ready" radios?  Are those worth the money?  What is it?
  475.  
  476. Can you attach the KPC-9612 to a HT and run it at 1200 anyway?  I have
  477. visions of plugging a 9-volt into the TNC, and taking my HT and Newton out
  478. and run packet away from the apartment. :-)
  479.  
  480. Also, can the KPC-9612 do HF packet?
  481.  
  482. Bob N2KGO
  483. -- 
  484. Bob Snyder
  485. rsnyder@astro.ge.com
  486.  
  487. ------------------------------
  488.  
  489. End of Ham-Digital Digest V94 #306
  490. ******************************
  491.